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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 1 of a multi-part deliverable covering the DVB Interactive Satellite System specification 
as identified below: 

TS 101 545-1: "Overview and System Level specification"; 

EN 301 545-2: "Lower Layers for Satellite standard"; 

TS 101 545-3: "Higher Layers for Satellite Specification". 



Introduction 



EN 301 790 [1] defines the first generation of DVB-RCS which is a system providing an interaction channel for satellite 
distribution systems. Together with its guidelines (TR 101 790 [i.l]) the specification describes how such system can be 
built on the physical and MAC layers to provide an efficient way of turning a satellite broadcast TV into a full VS AT 
solution capable of transporting IP traffic in a satellite-only system. 

Since the original definition of DVB-RCS systems, several versions of the specification were issued, describing the 
requirements for the implementation of a system providing an interaction channel for satellite distribution systems. 
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The sum of these specifications allowed to adapt the DVB-RCS systems to different market segments from small to 
large networks and from fixed to mobile terminals but it appears that the evolutions of the physical layer techniques and 
the stabilisation of IP standards now deserves deeper changes which can only be implemented in a consistent way via 
the definition of a second generation system. 

The requirements in the present document have been introduced in order to provide the best possible interoperability 
between terminals and hubs, thus defining not only the lower layers of the system (up to layer 2) but also network 
functions as well as management and control capabilities. 

As these specifications combined together may end up in a very complex terminal design, the specification also 
describes subsets of capabilities known as profiles that can be used together to address a given market segment. 
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Scope 



,nd , 



The present document establishes the system specifications for the 2 Generation Interactive DVB SatelUte System 
(DVB-RCS2) and represents the first part of the multi-part specification of that system. It also gives links to the 
adequate sections into the detailed specification documents and explains how the features must be combined together to 
make a terminal compliant with different subsets of specifications mentioned here as profiles. 

General terms and definitions are given in the present document which can be found also in the other parts of the DVB- 
RCS2 multi-part specification. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI EN 301 790: "Digital Video Broadcasting (DVB); Interaction channel for satellite 

distribution systems". 

[2] ETSI EN 301 545-2: "Digital Video Broadcasting (DVB); Second Generation DVB Interactive 

SatelUte System (DVB-RCS2); Part 2: Lower Layers for Satellite standard". 

[3] ETSI TS 101 545-3: "Digital Video Broadcasting (DVB); Second Generation DVB Interactive 

SatelUte System (DVB-RCS2); Part 3: Higher Layers Satellite Specification". 

[4] IETF RFC 3917: "Requirements for IP Flow Information Export (IPFIX)". 

[5] IETF RFC 5474: "A Framework for Packet Selection and Reporting" . 

[6] IETF RFC 1213: "Management Information Base for Network Management of TCP/IP-based 

internets: MIB-II". 

[7] IETF RFC 1901: "Inti'oduction to Community-based SNMPv2". 

[8] IETF RFC 1908: "Coexistence between Version 1 and Version 2 of the Internet-standard Network 

Management Framework" . 

[9] European Telecommunication Satellite Organization: "Digital Satellite Equipment Control 

(DiSEqCTM) Bus specification". 

[10] IETF RFC 5728: "The SatLabs Group DVB-RCS MIB". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 101 790: "Digital Video Broadcasting (DVB); Interaction channel for SatelUte 

Distribution Systems; Guidelines for the use of EN 301 790". 
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Definitions, symbols and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

control plane: communications that carry mainly signalling information 

Layer 1 Mesh Overlay System: satellite interactive network that supplements the unidirectional satellite link from a 
TDM feeder to RCSTs and the unidirectional satellite link from RCSTs to an MF-TDMA gateway with two-way 
satellite links between the RCSTs 

NOTE: In such systems, the NCC is connected to the RCST via the feeder and gateway. 

Layer 1 Regenerative and Re-multiplexing System: satellite interactive network that relies on an on-board 
regenerative processor to demodulate upcoming MF-TDMA data from terminals and generate a TDM downlink signal 
with this data 

NOTE: Such system looks like an RCS second generation system from the layer 1 RCSTs perspective. 

management plane: communications that carry information to maintain the network and to perform operational 
functions 

user plane: communications that carry user information 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

a Roll-off factor 

Eb/NO Ratio between the energy per information bit and single sided noise power spectral density 

Es/NO Ratio between the energy per transmitted symbol and single sided noise power spectral density 

fO Carrier frequency 

fN Nyquist frequency 

NR,max Number of replicas in a frame 

Nrand 12-bit random number used as a random seed value during CRDSA frame decoding 

Nslots Number of the slots in the frame 

Rs Symbol rate corresponding to the bilateral Nyquist bandwidth of the modulated signal 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACM Adaptive Coding and Modulation 

CCM Constant Coding and Modulation 

CLI Command Line Interface 

CPM Continuous Phase Modulation (or Modulator) 

CRC32 Cyclic Redundancy Check (32 bits) 

CRDSA Contention Resolution DSA 

DA Dedicated Access 

DHCP Dynamic Host Control Protocol 

DoS Denial-of-Services 

DSA Diversity Slotted Aloha 

DTP Digital Transparent Processor 

DVB-RCS Digital Video Broadcasting Return Channel by Satellite 

DVB-RCS2 Digital Video Broadcasting - Interactive Satellite System, Return Channel by Satellite second 

generation 
DVB-S2 Digital Video Broadcasting - Second generation framing structure, channel coding and modulation 

systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite 

applications 
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FEC Forward Error Correction 

FL Forward Link 

GS Generic Stream 

GSE Generic Stream Encapsulation 

HAIPE High Assurance Internet Protocol Encryptor 

HTTP Hyper Text Transfer Protocol 

ID IDentifier 

IPDR Internet Protocol Detail Record 

IPFIX Internet Protocol Flow Information Export 

IPv4 Internet Protocol, version 4 

IPv6 Internet Protocol, version 6 

ISI Input Stream Identifier 

LL Link Layer 

MAC Medium Access Control 

MF-TDMA Multiple-Frequency Time-Division Multiple Access 

MIB Management Information Base 

MUC Multiplier Up Converter 

NCC Network Control Center 

NCR Network Control Reference 

NMC Network Management Center 

OBP On-Board Processor 

OSPF Open Shortest Path First 

OVN Operator Virtual Networks 

PDU Protocol Data Unit 

PEP Performance Enhancing Proxy 

PSAMP Packet Sampling 

PSK Phase Shift Keying 

QAM Quadrature Amplitude Modulation 

QoS Quality of Service 

RCST Return Channel Satellite Terminal 

RL Return Link 

RLE RL Encapsulation 

RSGW Regenerative Satellite Gate Way 

SCADA Supervisory Control And Data Acquisition 

SLA Service Level Agreement 

SNMP Simple Network Management Protocol 

SNO Satellite Network Operator 

SO Satellite Operator 

SOC Satellite Operations Center 

SVN Satellite Virtual Network 

SVNO Satellite Virtual Network Operator 

SYNC SYNChronisation (byte, burst) 

TDM Time-Division Mode 

TLS Transport Layer Security 

TRANSEC TRANSmission SECurity 

TS MPEG2 Transport Stream 

TSGW Transparent SatelUte GateWay 

XML extensible Markup Language 



System definition 



4.1 



General 



DVB-RCS2 is the standard conceived to provide a standardised broadband interactivity connection as an extension of 
the Digital Video Broadcasting Satellite systems. It defines the MAC and physical layer protocols of the air interface 
used between the satellite operator hub and the interactive user terminal as well as the network layer and the essential 
functions of the management and control planes of the terminal. It embraces the GSE and the DVB-S2 standards 
implemented in the commercial broadcasting environment, exploiting economics of scale. 
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In order to provide a real interoperability, the DVB-RCS2 specification describes Higher layers components adapted to 
satellite interactive systems. These component are parts of control and management planes and rely mainly on DVB and 
IETF standards or are derived from them. 

A typical DVB-RCS2 Network will utilise a satellite with multi or single beam coverage. In most networks, the satellite 
carrying the forward link signal will also support the return link. The forward link carries signalling from the NCC and 
user traffic to RCSTs. The signalling from the Network Control Centre (NCC) to RCSTs that is required to operate the 
return link system is called "Forward Link Signalling". A Network Management Centre (NMC) provides overall 
management of the system elements and manages the Service Level Agreement (SLA) assigned to each RCST. 

The following network topologies are addressed by the present document: 

• Transparent star network system. 

• Transparent star network system with contention access. 
Future releases of the system are foreseen and they will cover: 

• Layer 1 transparent mesh overlay system with dedicated or contention access. 

• Regenerative mesh systems switching at different layers. 

These network topologies can be summarized in two main reference architectures, shown in figures 1 and 2 hereafter, 
transparent and regenerative. The actors of both interactive systems are the same and can be observed in figure 3: 

• Transparent system: 

Transparent satellite(s). One or more transparent satellites provide the link between terminals and the 
Hub, or among terminals for the transparent mesh system. Digital Transparent Processor (DTP) payloads 
can also give multi-beam connectivity. 

Hub/NCC. Performs the control (NCC), management (NMC) functions and interfaces user plane (traffic 
gateway) functions. 

Star or mesh overlay terminals (RCSTs).The star transparent terminal complies with the specifications of 
the DVB-RCS2 standard, providing star connectivity, or mesh connectivity with a double satellite hop. 
The mesh overlay transparent terminal is more complex, it includes two or more demodulators (adapted 
to DVB-S2 or RCST-TX waveform) and provides both single-hop mesh and star connectivity. 
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FL 
DVB-S2/GSE 



SAT-OBP 



^ 



RCST-TX/RLE 



SVNO 

Satellite Virtual 

Network Operator 




NCC/GW 

NMC 

SNO 

Satellite 

Network Operator 



Other 
Networks 



SOC 

SO 

Satellite Operator 

Figure 1 : Main roles on transparent satellite interactive network 

Regenerative system (future release): 

Regenerative satellite. Performs demodulation, demultiplexing, decoding (and possibly decapsulation) 
functions at the receiver side, on-board switching (at layer 2 or 3) for multi-beam systems, and the 
corresponding transmission functions after signal regeneration. 

Management Station. It provides the management (NMC) and control (NCC) plane functions to the 
satellite network users. 

Regenerative Satellite Gateway (RSGW). A RSGW provides regenerative RCST users with access to 
terrestrial networks. There may be one RSGW giving service to a small number of terminals, or to 
hundreds of terminals. Essentially, they comprise one RCST, plus an SLA Enforcer and an access router, 
but may also include voice, traffic acceleration servers, or a backhauling module. 

Regenerative terminals. These RCSTs are identical in terms of hardware to the star transparent terminals. 
The software includes C2P functionality to support dynamic mesh connectivity. 
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NOTE: Figure 2 only represents a potential architecture that should be further investigated in future releases of 
the DVB-RCS2. The mesh contexts should have interoperability profiles defined in conjunction with the 
supplemental specification of the mesh control protocol that will operate on the concepts supported in the 
specific profile. It is expected that variants may exist. The complete control protocol for transparent star 
operation is specified in EN 301 545-2 [2] and TS 101 545-3 [3], including profiles for transparent star. 

Figure 2: Example of main actors in a DVB-RCS2 system with regenerative satellite 
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4.2 System Roles 



The system roles considered in a DVB-RCS2 interactive system are presented in the model shown in figure 3. 
Satellite Systems 



DVB Network 



Interactive 

Networit no 



OVN Ni 



SVN N2 



RCST 




Satellite Operator 




Satellite Network 
Operator 



NOx NCC/Hub 



NMC Master 



Satellite Virtual 
Networif Operator 




TS-GWs 

RS-GWs NI^/IC Client 



Service Management 
Network Management 
Element Management 



Service Management 
Network Management 
Element Management 




RCSTs RS-GWs 



Figure 3: DVB-RCS2 actors and roles 

1) Satellite Operator (SO), who manages the whole satellite, and sells capacity at transponder level to one or 
several SNOs. 

2) Satellite Network Operators (SNO), are assigned one or more satellite transponders. Each SNO owns one or 
more NCC/NMC, and configures the time/frequency plan. Each SNO is responsible for one IN, corresponding 
to one DVB network (identified by the Network_ID), controlling their own capacity. The SNO may divide the 
interactive network into one or more Operator Virtual Networks (OVN). Each OVN is an independently 
managed higher layer network, and is managed by a SVNO. SNOs distribute their own physical and logical 
resources among OVNs. In the transparent architecture the SNO owns the TS-GW. 

3) Satellite Virtual Network Operators (SVNO), are assigned one or more Operator Virtual Networks (OVN), 
each being given some physical and logical resources. An active RCST can only be a member of one OVN, 
This is assigned at logon to the DVB-RCS2 Network. Each OVN is assigned a pool of SVN numbers from 
which it can allocate SVN-MAC addresses. The SVN concept is used to logically divide the addressing space 
controlled by the operator. SVNOs sell connectivity services to their subscribers and for the regenerative 
architecture may also manage one or several RSGWs. 

4) Subscriber (RCST), are the user stations, which they contract to the SVNOs. 

5) End-user are the final actors enjoying the satellite services, connected to the RCST LAN interface. 



4.3 Physical layer 



The physical layer of a DVB-RCS2 compliant terminal operating in a DVB-RCS2 system shall comply with the 
specifications defined in EN 301 545-2 [2]. Not all specifications need to be implemented depending on the terminal 
profile (see table 3) and also on supported options (see table 2). The specification of the elements which are optional or 
normative as well as the profiles and their related options are described in clause 4.11 Terminal capabilities and 
profiles. 
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4.4 Access layer 



The access layer of a DVB-RCS2 compliant terminal operating in a DVB-RCS2 system shall comply with the 
specifications defined in EN 301 545-2 [2]. Not all specifications need to be implemented depending on the terminal 
profile (see table 3) and also on supported options (see table 2). The specification of the elements which are optional or 
normative as well as the profiles and their related options are described in clause 4.11 Terminal capabilities and 
profiles. 



4.5 System architecture 



The architecture of a DVB-RCS2 compliant terminal shall be compatible with the system architecture specified in 
TS 101 545-3 [3]. 



4.6 Network layer 



The network layer of a DVB-RCS2 compliant terminal shall follow the specifications indicated in TS 101 545-3 [3]. 
Some of these specifications are optional and may be required to meet some of the defined terminals profiles, refer to 
clause 4. 11 Terminal capabilities and profiles of the present document for the details of these specifications. 



4.7 Management functions 



The management functions of a DVB-RCS2 compliant terminal shall follow the specifications indicated in 

TS 101 545-3 [3]. Some of these specifications are optional and maybe required to meet some of the defined terminals 

profiles, refer to clause 4. 1 1 Terminal capabilities and profiles of the present document for the details of these 

specifications. 



4.8 Traffic interception 



The traffic interception functions of a DVB-RCS2 compliant terminal shall follow the specifications indicated in 
TS 101 545-3 [3]. These specifications are optional and are not required for any profile. 

4.9 Terminal installation functions 

The terminal installation functions of a DVB-RCS2 compliant terminal shall follow the specifications indicated in 
TS 101 545-3 [3]. The potential waveforms to be used for the installation procedure are described in EN 301 545-2 [2]. 
The motor control commands shall follow DiSEqC^'^ [9] specification. Implementation of these control commands are 
optional as indicated in table 2 and are not required for any profile. 

4.10 Terminal future configurations [informational] 

Terminals capabilities defined in EN 301 545-2 [2] and TS 101 545-3 [3] cover essential use of the DVB-RCS2 
systems. This informational clause provides some insight of future usages of the system which are foreseen in the scope 
of mobile applications, mesh connectivity with or without regenerative satellites, improved return link efficiency and 
will be defined in new versions of the current set of specifications. 

These usages are relying on the implementation of a set of capabilities already specified in DVB-RCS (EN 301 790 [1]) 
which will probably be modified for DVB-RCS2 systems. As such, they are mentioned as reserved, which means they 
are not re-defined yet but will be part of future specifications in a new configuration. 
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Table 1 : Terminal future configurations options 



Terminal feature 


Comment 


PHYSICAL LAYER 




Continuous carrier support on the return linl< 


Mainly for mobile but potentially for backhauling 


IVIobile pliysical layer options (e.g. spreading, BSPK, etc.) 


Mobile and small aperture terminals 


OFDIVIA support on the return linl< 


Improvement of the return link efficiency 


MAC LAYER 




Transparent mesh overlay support 


Transparent mesh systems 


Regenerative satellite support 


Regenerative mesh systems 


Mobile MAC features 


Features comprising Link-Layer FEC, pro-active 
retransmission, for mobile systems 


Network LAYER 




GSM/ WiMax backhauling 


Requires further investigation to assess which 
optimisations are required 


IP Gateway implementation 


To be further defined 


Management LAYER 




Mobility management via lower layer 


Applicable to mobile systems 



4.1 1 Terminal capabilities and profiles 

Systems implementing DVB-RCS2 standard are not mandated to implement all features defined in the lower layers and 
higher layer satellite specifications documents. In order to better match DVB-RCS2 systems with their potential uses, a 
set of terminal profiles and features is defined in this clause. 

Terminal optional features are defined as a set of capabilities that a terminal can implement or not depending on its 
design. Implementation of these features depends on the manufacturer decision and represents a competitive 
differentiation with respect to other designs. Normative features shall be implemented by all DVB-RCS2 terminals. 

The fact that these features are implemented or not does not prevent the terminal to be interoperable with hubs as the 
hub should be aware of the implementation of these features via signalling. 
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Table 2: Terminal features description 



Terminal feature 


Normative/ 
Optional 


Comment 


PHYSICAL LAYER 






QPSK/8PSK and CPM support on the return link 


N 




Reference waveforms 


N 




Custom waveforms 







Waveform bound permanently to timeslot 


N 


Definition via tables 


Waveform allocated to timeslots at the time of 
assignment 


N 


Dynamic allocation via burst assignment 


EIRP power control 


N 


For RCST not using MUC with CPM 


Constant Power Density control 







Forward link DVB-S2 CCM, S2 ACM 


N 




Forward Link Single Continuous Generic Stream 


N 




Forward link Single TS Packet Stream 





For migration support 


Forward link Multiple Streams (TS or GS) 







GSE in BBframe CRC32 


N 




MAC LAYER 






DAMA for traffic (supporting all capacity categories) 


N 




Unsolicited DA for traffic 


N 




Slotted Aloha logon 


N 




Random Access combined with DAMA 







Random access with replicas 





Constant of variable rate replication ratio 


In-band signalling in traffic timeslots 


N 




Signalling in DA signalling timeslots 


N 




NETWORK LAYER 






DHCP on LAN interface 


N 


For IPv4 and IPv6 as specified in TS 101 545-3 [3] 


IPv4 and IPv6 support on traffic interface 


N 




Static multicast support 


N 




Dynamic multicast support 







Static IP routing support 


N 




DiffServ QoS support 


N 




MPLS support 







CONTROL FUNCTIONS 






Motor control support 





Via DiSeqC'" 2.x supporf [9] 


MANAGEMENT PLANE 






IPV4 support on management interface 


N 




IPV6 support on management interface 







Multicast software download 


N 


Specified in TS 101 545-3 [3] 


Support of RCS2 MIB 


N 


Specified in TS 101 545-3 [3] (SatLabs MIB), will 
be further inserted in an updated version of 
RFC 5728 [10] 


PEP negotiation protocol support 


0/N 


Based on the signalling by the terminal of its 
hardware and software versions 


XML file based configuration support 





Find spec in TS 101 545-3 [3] 


SNMP V2c 


N 


Specified in RFC 1901 [7] - RFC 1908 [8] 


SNMPMIBII 


N 


Specified in RFC 1213 [6] 


SNMP and CLI remote control via layer 2 





Based on layer 2 tunnelling. Refer to it in the LL 
specification 


Lower Layer Signalling RCST remote control 


N 




Authenticated logon 







Lower Layer IPv4 M&C address assign 


N 




IPDR support 







Syslog support 







HTTP management interface supporf 


N 





In addition to the terminals features, a set of profiles is defined. Capabilities used as keys for profiling allow system 
designers to identify a set of minimum specifications for a terminal that declares its compliance to a given profile. A 
terminal can comply with several profiles and implement features or have performances above those defined in table 3. 
The requirements in this clause should be understood as minimum capabilities for a terminal to be declared as 
compliant to a usage profile. 
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Table 3: Terminal profiles description 
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PHYSICAL LAYER 














16 QAM return link modulation 








N 





N 


N 


32APSK Forward Link modulation 














N 


N 


Essential waveform flexibility 








N 





N 


N 


Fast carrier switching 








N 





N 


N 


Lowest carrier switching class 


1 


1 


2 


1 


2 


2 


MAC LAYER 














Minimum number of supported traffic SVN 


1 


4 


4 


1 


4 


4 


Minimum number of layer 2 traffic classes (request classes and 
allocation channels) 


3 


3 


7 


3 


3 


7 


Slotted Aloha traffic 











N 








TRANSEC hooks support 

















N 


NETWORK LAYER 














Minimum number of simultaneous traffic multicast streams reception 


16 


64 


64 


16 


16 


64 


Dynamic IP routing via OSPF support 





N 


N 





N 


N 


Firewall capability 








N 


N 





N 


Multicast forwarding on the return link 

















N 


MANAGEMENT LAYER 














SNMP v3 support (*) 





N 


N 





N 


N 


Multi SVNO support 





N 














N: Normative capability required for this profile. 
0: Optional capability not required for this profile. 

(*) SNMP V2c is required as a minimum for all terminals profiles while SNMP V3 should be 
normative unless specified optional. 



4.12 System versioning 



The scope of version 2 designated as the DVB-RCS2standard is extended significantly compared to that of version 1 as 
defined in EN 301 790 [1] and designated as DVB-RCS. In particular, DVB-RCS2 contains mandatory provisions for 
the management and control planes. Furthermore, in order to enhance efficiency, this version has introduced a 
significant number of non-backwards-compatible changes to certain mandatory provisions that are covered in both 
versions. This applies, inter alia, to the encapsulation, modulation and coding of the return link transmissions, as well as 
to the carriage of signalling in the forward link. 

These changes have been introduced in a manner that facilitates a smooth migration from Version 1 to Version 2, with 
minimal operational impact. It is envisaged that such a migration may take place over an extended period of time. In 
particular, already-deployed RCST's operating according to Version 1 may not be software-upgradeable to Version 2, so 
a system operator may choose to operate according to Version 2 only on newly-deployed and replaced terminals. 
Accordingly, Version 1 may only be phased out as existing terminals reach the end of their operational life. It is 
therefore very important that the two versions can co-exist within a system and share the resources in an efficient 
manner. 

Clause 4.12.1 describes the envisaged scenarios and associated normative provisions for forward links; clause 4.12.2 
presents the corresponding provisions for return and mesh links. Some considerations for Management and Control 
Planes, Synchronisation and Logon are presented in clauses 4.12.3 and 4.12.4. 
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4.12.1 Forward Link 

Migration scenarios for the forward link depend on the starting point. The forward link in DVB-RCS Version 2 is 
intended to use the Generic Stream Encapsulation protocol exclusively, including for transport of signalling. In 
DVB-RCS (EN 301 790 [1]) specification, one or more Transport Streams are used to carry traffic and signalling. 

The multi-input-stream capabilities of DVB-S2 can be exploited to allow sharing of a physical forward link carrier 
among RCST populations operating according to both versions. This greatly facilitates migration, in particular for 
systems employing a forward link that occupies a complete transponder. Avoiding multi-carrier operation eliminates the 
need to back off the transponder during the migration. 

Carrier sharing is not possible if the original system uses DVB-S or include RCST's that support only the minimum 
functionality mandated for DVB-S2 (CCM with single input transport stream). 

As a special provision to facilitate migration. Version 2 RCST's may be able to extract forward link traffic and 
signalling from a Transport Stream. This optional feature provides tools that facilitate the migration process. This 
feature ameliorates restrictions dictated by fundamental differences between forward link carriers, in particular between 
DVB-S and DVB-S2. By using this optional feature, it is possible to design hybrid migration scenarios for the overall 
system, in which the forward and return links are migrated separately. For example, a DVB-RCS forward link can be 
used to transport traffic and signalling to both DVB-RCS and DVB-RCS2 capable RCST's. The latter may in turn use a 
DVB-RCS2 return Hnk. 

Table 4 summarises the main issues associated with forward link migration from different starting points, in order of 
decreasing system impact. These are examples only; it is expected that details will be system-specific. It is further noted 
that there are no known DVB-RCS implementations that make use of Generic Streams for carrying traffic. Migration 
scenarios starting from Generic Streams have therefore not been considered. Some additional considerations are 
presented following table 4. 

Table 4: Forward link migration scenarios 



Migrating From 


Main Considerations 


DVB-S 


The carrier cannot be strictly Version-2 compliant, but can transport 
DVB-RCS2 information in a hybrid migration scenario. 


DVB-S2 CCM with MPE (single- 
stream capable receivers) 


The carrier cannot be strictly DVB-RCS2 compliant, but can transport 
DVB-RCS2 information in a hybrid migration scenario. 


DVB-S2 CCM with MPE (multi-stream 
capable receivers) 


During the migration, at least one TS is retained to carry traffic for 
DVB-RCS terminals. This TS will also carry signalling. 

Although not strictly required, for best efficiency one or more GS's should 
carry the traffic for RCSTs. 


DVB-S2 ACM with MPE 


During the migration, at least one TS is retained to carry traffic for 
DVB-RCS terminals. This TS will also carry signalling. NCR packets can 
be shared by all RCS and RCS2 terminals. 

Although not strictly required, for best efficiency one or more GS's should 
carry the traffic for RCSTs. 



When migrating from a DVB-S forward link, there is no possibility of operating it strictly according to DVB-RCS2. 
However, if a hybrid migration arrangement is acceptable, the DVB-S carrier can be used to transport traffic and 
signalling DVB-RCS2 terminals, as described above. To support DVB-RCS2 terminals without the migration option, it 
is necessary to run the DVB-RCS2 component through a separate forward link. The relative carrier rates can be adjusted 
over time to match the traffic demands in the two components, as this evolves from DVB-RCS to DVB-RCS2. If the 
original system operates in a quasi-linear, shared transponder, this will have little impact on the system efficiency - in 
fact, the higher efficiency of the DVB-S2-based DVB-RCS2 system will likely more than compensate for the added 
overhead incurred due to duplication of certain elements of signalling, etc. If the original system uses a full transponder 
operated near saturation, it will be necessary either to provide additional capacity for the new carrier, or to back off the 
transponder to allow two-carrier operation. In the latter case, some capacity loss in the migration period is probably 
inevitable. 

If the terminal in the original system allows it, this capacity loss can be further mitigated by carrying out the migration 
in two steps: by first switching to DVB-S2 operation in DVB-RCS, and subsequently introducing DVB-RCS2 operation 
on the shared carrier as described below. 
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A similar situation occurs if the original system uses DVB-S2 but includes DVB-RCS terminals that implement only the 
bare minimum required by the DVB-S2 standard (CCM with single transport stream). In this case, the multi-stream 
capabilities of DVB-S2 cannot be exploited, so it is again necessary either to use separate forward link carriers or to 
transport DVB-RCS2 traffic and signalling on the DVB-RCS carrier in a hybrid migration arrangement. 

Apart from this case, the migration path from a DVB-S2 based DVB-RCS system depends on how the original system 
is operated; in particular on whether the original system is CCM or ACM. This distinction arises from the fact that 
DVB-RCS carries the NCR synchronisation information in different ways, depending on the mode. The method used in 
DVB-RCS2 is analogous to that used in DVB-RCS with ACM, while that used with CCM in DVB-RCS is substantially 
different. When migrating from a DVB-RCS CCM system, it may therefore be necessary to carry two separate sets of 
NCR packets: One transmitted according to the CCM method, one according to the ACM/DVB-RCS2 method. This 
depends on whether the backwards compatibility of the DVB-RCS2 terminals extends to supporting the CCM NCR 
method. 

One or more Transport Streams must be retained during the migration to carry traffic to DVB-RCS terminals as well as 
to carry some or all signalling. For best efficiency, one or more OS's should be added to the carrier to handle traffic to 
DVB-RCS2 terminals. 

In all DVB-S2 migration scenarios, input streams are separated by ISI value and no explicit re-configuration is required 
at the DVB-S2 level in order to apportion capacity among the two terminal populations. 

4.12.2 Return link 

While the basic MF-TDMA nature of the return Unk has been retained from DVB-RCS to DVB-RCS2, incompatible 
changes have been introduced to the encapsulation (variable-payload RLE vs. fixed-payload ATM/MPEG), FEC coding 
(16-state vs. 8-state turbo code), burst formatting (distributed pilots vs. preamble-only), modulation (extension to 8PSK 
and 16QAM) and dynamic operation (rapid changes to the time slot parameters). It is envisaged that these changes will 
necessitate corresponding changes to the resource management functions. As a result of this, the recommended resource 
sharing method in the return link during migration from DVB-RCS to DVB-RCS2 is to exploit the multi-carrier nature 
of the transmission scheme, configuring separate sets of carriers with appropriate characteristics and capacity for the 
two terminals populations. This configuration will evolve over time, as the usage of DVB-RCS decreases and that of 
DVB-RCS2 increases. In all but the smallest systems, this will provide a relatively fine granularity for the capacity 
sharing. The partitioning will however be quasi-static, so some loss of capacity can be encountered. This loss is 
however at least partly compensated by the better power/bandwidth efficiency of Version 2, and can be further 
mitigated by the special logon provisions described below. 

It is conceivable that individual carriers can be shared between DVB-RCS and DVB-RCS2, by a judicious design of the 
frame formats that create non-overlapping resources for the two elements (e.g. letting the first half of each superframe 
be DVB-RCS and the second half DVB-RCS2). This may be of interest particularly for very small systems. There are 
no special normative provisions to support this type of operation; implementation is left to individual vendors and 
system operators. 

4.1 2.3 Management and Control Planes 

Management and control plane functions above the MAC layer are outside the scope of DVB-RCS, with systems 
relying largely on vendor-specific provisions. By definition, there is therefore no interoperable migration path to 
DVB-RCS2 for these aspects. 



4.12.4 RCST Synchronisation and Logon 



Both versions of the standard have defined ways of locating the forward link carrier and the (TS or GS) stream carrying 
the signalling; based on the population_id and other fundamental parameters configured in each terminal. As a 
minimum, any terminal attempting to enter the system will therefore be able to locate the appropriate resources 
unambiguously and will therefore also be able to attempt logon in the appropriate partition of the return link resource. 

Furthermore, as a migration aid, DVB-RCS2 includes an optional, backwards-compatible variant of the logon (CSC) 
burst from DVB-RCS. This variant allows the terminals to indicate its DVB-RCS2 capabilities as well as whether it can 
operate fully in accordance with DVB-RCS. This feature allows the NCC to make the decision about the version to be 
used for any session at logon time, rather than using a pre-determined configuration. This can be used for example for 
load balancing, hence minimising the impact of the resource partitioning between DVB-RCS and DVB-RCS2. 
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4.13 Security aspects 



This clause addresses system security issues - concerned with protection of the network itself - as well as lawful 
interception of traffic. 

System security comprises Confidentially, Integrity, Availability and Non-Repudiation. Each of these attributes can be 
associated with the U-Plane, C-Plane and M-Plane; the corresponding functional security needs are summarised in 
table 5. 

Table 5: High-level security requirements 





Confidentiality 


Integrity 


Availability 


Non-repudiation 


U-plane 


Protection of unencrypted 
data and header 
information 


Use of standard 
techniques (e.g. CRC, 
sequence numbers) 




Provided by IPsecor 
HAIPE 


C-plane 


Protection of User Traffic 
activity patterns and 
capacity requests 


Use of standard 
techniques (e.g. CRC, 
sequence numbers) 


Protection against 
Denial of Service 
attack 


User, Hub and RCST 
authentication 


M-plane 


Protection of signalling; 
protection from Terminal 
Location Analysis 


Use of standard 
techniques (e.g. CRC, 
sequence numbers) 


Protection against 
Denial of Service 
attack 


User, Hub and RCST 
authentication 



The security aspects addressed in DVB-RCS2 are represented by highlighting in table 5. Correspondingly, for the 
purposes of the standard, security has been defined to include: 

• Control, management and data confidentiality and integrity: 

Risk of channel activity patterns tracking: disguise transmission energy in order to conceal channel 
activity fluctuations. 

Risk of control channel information monitoring: disguise traffic volumes, secure traffic source and 
destination. 

Risk of user data eavesdropping: disguise user information. 

• Network access and connection establishment: 

Risk of hub and remote units faking: ensure that remote terminals connected to the network are 
authorized users. 

Intrusion risk: mitigate the intrusion risk / protect against Denial-of-Services (DoS) and Replay attacks. 

U-Plane security may be provided end-to-end using mechanisms outside the scope of the standard, e.g. IPsec (including 
HAIPE, High Assurance Internet Protocol Encryptor) or Transport Layer Security (TLS). 

Protocols implemented within an RCST and operating at the network-layer or above (e.g. IP-level functions, 
configuration, and management) can also present security vulnerabilities. As for the user plane, these can be secured 
using standards-based methods such as TCP secure, IPsec, and protocol-specific security extensions. Remedies for these 
issues are beyond the scope of standardisation. 

There are known interactions with end-to-end security mechanisms and RCST protocol acceleration mechanisms such 
as intercepting proxies. These mechanisms can partially deny opportunities for split-TCP, application-specific protocol 
acceleration, compression, cross-layer QoS optimisation, etc., since these techniques require visibility of protocol 
headers (and in some cases the ability to modify them). This conflicts with the security goals. Remedies for these issues 
are system specific and beyond the scope of the present document. 
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4.1 3.1 Transmission Security (TRANSEC) 



The countermeasure techniques commonly used for mitigating security risks in the management and control planes are 
known as TRANSEC. The techniques foreseen in the standard include link layer encryption including its associated key 
management, authentication and traffic activity concealment/obfuscation. The normative document provides features 
for transport of the information associated with these countermeasures, including for example encryption key exchange 
messages, initialisation vectors and authentication handshaking. Given that specific requirements and preferred 
techniques vary substantially between users, details of the techniques and associated signalling are outside the scope of 
the normative provisions. A number of implementations are described in the guidelines document. 

TRANSEC encryption can be applied in the link layer to both Forward Link (FL) and Return Link (RL) of a 
DVB-RCS2 network, to all data packets (payloads and headers) and to all signalling, with a small number of exceptions 
dictated by physical transport considerations. Link layer encryption is foreseen to be based on approved algorithms, 
used in approved modes of operations. For military and governmental applications the encryption algorithms and the 
operation modes will normally be military approved. 

On the forward link, the traffic activity can be concealed/obfuscated by transmitting dummy or "chaff packets in 
broadcast mode. On the return link, the traffic activity can be concealed / obfuscated by transmitting dummy bursts. The 
policies for slot allocation for dummy bursts are system specific. 

In order to ensure that transport of TRANSEC-specific information can take place in an interoperable manner, the 
following mandatory protocol types are defined for GSE in the forward link and RLE in return/mesh links: 

• TRANSEC_Chaff: This mandatory protocol type indicates that the packet contains meaningless "chaff or 
"dummy" data. The contents of such packets shall be discarded by the receiver. 

• TRANSEC_Certificate: This mandatory protocol type indicates that the packet contains certificate exchange 
information for control of a TRANSEC function. The packet contents are implementation-specific. Such 
packets can be discarded by receivers not implementing TRANSEC. 

The corresponding protocol type values are assigned by the IETF. 

4.13.2 Lawful Interception 

A DVB-RCS2 Network may need to consider the requirements for lawful interception of user traffic. These 
requirements vary depending on location and local legislation. 

For star networks, lawful interception functionality may be provided at the hub. 

In mesh networks, the opportunities for lawful interception are system dependent. OBP-based mesh networks typically 
assemble all transmissions into a single TDM per beam, so interception can be achieved by the same means as for star 
networks, by employing a single receiving station in each beam. This function will normally be available at the NCC in 
any case. 

Some transparent mesh networks also have a reception function at the hub, where all traffic can be monitored. Although 
usually intended for extraction of signalling, this function can also be used for lawful interception. 

In those transparent mesh networks where no central traffic monitoring is available as part of the normal system 
operation, it may be necessary to install dedicated monitoring facilities in each beam. 

A number of existing techniques may be used for interception of traffic in IP networks, including DVB-ISS networks. 
These include for example IPFIX (Internet Protocol Flow Information Export) (RFC 3917 [4]) and PSAMP (Packet 
Sampling) (RFC 5474 [5]). The former is an IETF standard for common export of Internet Protocol flow information 
from routers, probes, and other devices. It is used by mediation systems, accounting/billing systems, and network 
management systems to facilitate services such as measurement, accounting, and billing. The PSAMP protocol allows 
packets to be selected from a stream according to a set of standardised selectors, to form a stream of reports on the 
selected packets, and to export the reports to a collector using the IPFIX framework. The details of these techniques, 
and the manner in which they are applied, are outside the scope of the standard. 

4.14 Evaluation and certification 

Intentionally left blank clause. 
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